System and method for splitting a fee for an on-demand service

ABSTRACT

A method for determining a fare for a transport service is provided. One or more processors determine that the transport service is in progress for a first user. A request to share the fare for the transport service in progress with a second user is received over a network from a first computing device of the first user. A confirmation that indicates that the second user is to share the fare is received over the network from a second computing device of the second user. A first amount of the fare for the first user and a second amount of the fare for the second user is determined.

RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.14/311,782 filed Jun. 23, 2014, which claims benefit of priority to U.S.Provisional Patent Application No. 61/842,599, filed Jul. 3, 2013; theaforementioned priority applications being hereby fully incorporated byreference herein in their entireties.

BACKGROUND

An on-demand service system can arrange a service between a requestingparty and a service provider. In some examples, such on-demand servicescan include transport services, food services, or delivery services.Once the on-demand service has been completed, the requesting party cantypically pay for the services using cash or using a credit or bankaccount.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example system for splitting a fee for anon-demand service.

FIG. 2 illustrates an example method for splitting a fee for anon-demand service.

FIGS. 3A through 3E illustrate example user interfaces that aredisplayed on a computing device for splitting a fee for an on-demandservice.

FIGS. 4A through 4C illustrate other example user interfaces that aredisplayed on a computing device for splitting a fee for an on-demandservice.

FIG. 5 is a block diagram that illustrates a computer system upon whichexamples described herein may be implemented.

FIG. 6 is a block diagram that illustrates a mobile computing deviceupon which examples described herein may be implemented.

DETAILED DESCRIPTION

Examples described herein provide for a system to enable fees or faresfor an on-demand service, such as a transport service, to be sharedamong multiple users. Still further, the system can enable a user todynamically change which users can share in the fee or fare for theon-demand service during performance of the service.

In some examples, a system can arrange an on-demand service to beperformed between a requesting party (e.g., a user) and a serviceprovider. The system can associate an account of the first user with thearranged service. During progress of the service, the system candetermine that the fee for the service is to be shared by two or moreusers by receiving user inputs from two or more computing devicesassociated with the two or more users. In one example, a first user canprovide a request to the system to share or split the fee for theservice with a second user during progress of the service. The systemcan notify the second user and receive a confirmation from the seconduser. The system can determine the fee for the service and therespective amounts each user is to pay.

The system can also determine the amount to be paid by each user thatshares in the fee for the service. Depending on implementation, thetotal fee can be split evenly (or substantially evenly) between thenumber of users that have agreed to share in the fee. In other examples,the fee can be split based on a variety of different parameters, such asinput provided by one or more users, the duration of the service, thedistance and/or direction(s) traveled by a service provider in providingthe service, when the user(s) agreed to share in the fee, when theuser(s) initially received at least part of the service, etc. Accordingto an example, once the system determines that the service has beencompleted, the system can charge the respective amounts to be paid byeach user to the corresponding accounts of the users.

According to some examples, the user can operate a service applicationor program on the user's mobile computing device. The serviceapplication can communicate with the system to enable the user torequest the on-demand service, select friends or contacts to share inthe fee for the on-demand service, request that the fee be split betweenthe user and the selected friends or contacts, and receive an indicationor confirmation of the fee splitting between the user and the selectedfriends or contacts. In this manner, the system can dynamically provideupdated information to the user about the fee for the service (e.g.,whether the fee is to be split and/or which friends are sharing in thefee) during progress of the service.

As described herein, a “user,” a “requester,” or a “customer” isinvariably used to refer to an individual that is requesting or orderinga service, and a “friend” or “contact” is used to refer to an individualthat receives a request to share in a fee or fare for the service. Alsoas described herein, a “provider,” a “service provider,” a “supplier,”or a “vendor” is invariably used to refer to an individual or entitythat can provide the service. As an example, a user can request aservice, such as a transportation or delivery service (e.g., fooddelivery, messenger service, food truck service, or product shipping) oran entertainment service (e.g., mariachi band, string quartet) using anon-demand service system, and a service provider, such as a driver, foodprovider, band, etc. can communicate with the system and/or the user toagree to provide the service. In addition, as described herein,“requesting devices,” “friends devices,” and “provider devices” refer tocomputing devices that can correspond to cellular or smartphones, laptopcomputers, tablet devices, network-enabled devices generally, etc., thatcan provide network connectivity and processing resources for enablingrespective individuals to communicate with the system over a network. Aprovider device can also correspond to taxi meters or other meteringdevices.

One or more examples described herein provide that methods, techniques,and actions performed by a computing device are performedprogrammatically, or as a computer-implemented method. Programmatically,as used herein, means through the use of code or computer-executableinstructions. These instructions can be stored in one or more memoryresources of the computing device. A programmatically performed step mayor may not be automatic.

One or more examples described herein can be implemented usingprogrammatic modules, engines, or components. A programmatic module,engine, or component can include a program, a sub-routine, a portion ofa program, or a software component or a hardware component capable ofperforming one or more stated tasks or functions. As used herein, amodule or component can exist on a hardware component independently ofother modules or components. Alternatively, a module or component can bea shared element or process of other modules, programs or machines.

Some examples described herein can generally require the use ofcomputing devices, including processing and memory resources. Forexample, one or more examples described herein may be implemented, inwhole or in part, on computing devices such as servers, desktopcomputers, cellular or smartphones, laptop computers, printers, digitalpicture frames, network equipment (e.g., routers) and tablet devices.Memory, processing, and network resources may all be used in connectionwith the establishment, use, or performance of any example describedherein (including with the performance of any method or with theimplementation of any system).

Furthermore, one or more examples described herein may be implementedthrough the use of instructions that are executable by one or moreprocessors. These instructions may be carried on a computer-readablemedium. Machines shown or described with figures below provide examplesof processing resources and computer-readable mediums on whichinstructions for implementing examples described herein can be carriedand/or executed. In particular, the numerous machines shown withexamples described herein include processor(s) and various forms ofmemory for holding data and instructions. Examples of computer-readablemediums include permanent memory storage devices, such as hard drives onpersonal computers or servers. Other examples of computer storagemediums include portable storage units, such as CD or DVD units, flashmemory (such as carried on smartphones, multifunctional devices ortablets), and magnetic memory. Computers, terminals, network enableddevices (e.g., mobile devices, such as cell phones) are all examples ofmachines and devices that utilize processors, memory, and instructionsstored on computer-readable mediums. Additionally, examples may beimplemented in the form of computer-programs, or a computer usablecarrier medium capable of carrying such a program.

System Description

FIG. 1 illustrates an example system for splitting a fee for anon-demand service. According to examples, the system can determine thatan on-demand service is pending or in progress for at least one user andenable the fee or fare for the service to be shared between multipleusers. The system can also communicate with devices of the users todynamically provide updated information regarding the service and theshared fees.

In one example, system 100 includes a fee distribution 110, a servicemanager 120, an accounts data store 130, a service data store 140, and adevice interface 150 to enable system 100 to communicate with othercomputing devices (such as a requesting device(s) 160 and friends'devices 170). A requesting device can refer to a computing deviceoperated by a user who requested the on-demand service and/or requestedto share or split the fee for the service with one or more other friendsor contacts. A friend device can refer to a computing device operated bya friend or contact of the user, who has the option whether to share thefee. The components of system 100 can combine to exchange communicationsbetween system 100 and other computing devices to enable fees or faresfor an arranged on-demand service to be shared by multiple users.

System 100 can operate in connection with an on-demand service system,which can enable an on-demand service to be arranged between one or moreusers who operate one or more requesting devices 160 and one or moreservice providers (e.g., individuals or entities who operate one or moreprovider devices, not shown in FIG. 1). For example, the service manager120 of system 100 can interface with or be a part of the on-demandservice system. Although the on-demand service can include a variety ofdifferent services (e.g., a transport service, a delivery service, afood truck service, an entertainment service, etc.), for illustrativepurposes, the examples herein is described with respect to an on-demandtransport service.

Depending on implementation, one or more components of system 100 can beimplemented on network side resources, such as on one or more servers.System 100 can also be implemented through other computer systems inalternative architectures (e.g., peer-to-peer networks, etc.). As anaddition or an alternative, some or all of the components of system 100can be implemented on client devices, such as through applications thatoperate on the requesting devices 160, the friends' devices 170, and/orthe provider devices. For example, a client application, such as aservice application, can execute to perform one or more of the processesdescribed by the various components of system 100. System 100 cancommunicate over a network, via a network interface (e.g., wirelessly orusing a wireline), to communicate with the one or more requestingdevices 160, the one or more friends' devices 170, and the one or moreprovider devices.

System 100 can communicate, over one or more networks, with requestingdevices 160 and provider devices using a device interface 150. Thedevice interface 150 can manage communications between system 100 andother computing devices. In some examples, the requesting devices 160(and friends' devices 170) can individually operate a serviceapplication that can interface with the device interface 150 tocommunicate with system 100. Similarly, service providers canindividually operate their respective provider devices to use a serviceapplication (e.g., a different application than the application used bya customer, or the same application) that can interface with the deviceinterface 150. According to some examples, the applications can includeor use an application programming interface (API), such as an externallyfacing API, to communicate data with the device interface 150. Theexternally facing API can provide access to system 100 via secure accesschannels over the network through any number of methods, such asweb-based forms, programmatic access via restful APIs, Simple ObjectAccess Protocol (SOAP), remote procedure call (RPC), scripting access,etc., while also providing secure access methods including key-basedaccess to ensure system 100 remains secure and only authorized users,service providers, and/or third parties can gain access to system 100.

A user operating a requesting device 160 can make a service request 161for an on-demand service, such as a transport service. The user canoperate the service application to input a request for pick up, a pickuplocation, and/or a destination location, for example, and the on-demandservice system can arrange for a service provider (e.g., a driver of avehicle) to provide the transport service. The service manager 120 canreceive the service request 161 and can associate an account (oridentifier of the account) of the user with an identifier for thetransport service. In this manner, the service manager 120 can keeptrack of the transport service that has been arranged, which user hasrequested and/or is being provided with the transport service, and whichservice provider (e.g., driver) is assigned to provide the arrangedtransport service. The described information for the transport servicecan be updated 121 in the service data store 140 as one of many entriescorresponding to a transport service.

In some examples, the on-demand service system can also monitor theprogress of the transport service, such as the time and/or distance awaythe driver is from the user for pickup, when the user is picked up bythe driver, the distance and/or direction(s) traveled by the driver forthe transport service, the duration of the transport service, when thetransport service has been completed, etc. The service manager 120 canupdate 121 the entry of the user's transport service in the service datastore 140 with the monitored information. The information can be used,for example, by the service manager 120 to determine the total fee orfare for the service and/or by the fee distribution 110 to determine howto partition or split the total fare between two or more users.

Once the transport service has been arranged, the user can viewinformation about the transport service on the user's respectivecomputing device 160. Such information can include an identification(e.g., a user name or actual name of the driver, the vehicle's licenseplate number, the driver's phone number or other contact information),an image of the driver, a status of the driver (e.g., “en route,”“arriving now,” or “in trip”), a car type, an estimated time of arrival,and/or a map showing the real-time location and/or movement of thedriver or the current location of the user. From the time the transportservice has been arranged for the user to the time the service providerindicates (e.g., via his or her provider device) that the transportservice has been completed, the user is provided with an option to sharethe fare for the transport service. This can be referred to as theduration of the transport service or a time in which the transportservice is in progress for the user.

For example, during progress of the transport service, the user caninteract with the service application to access a menu or optionsettings in which the user can select a feature to request splitting thefare. The user can request to split the fare when the driver is “enroute” to pick up the user, when the driver is “arriving now” at alocation of the user, or when the user has been picked up and is beingtransported to a destination (e.g., “in trip”). The user can make arequest 163 to split the fare by selecting one or more friends orcontacts from his or her requesting device 160. In one example, theservice application on the requesting device 160 can access the contacts(e.g., the contacts application, phone book, or email addresses) of theuser and enable the user to select one or more of the contacts. Theservice application an also enable the user to manually provide/enter ina phone number or other communication identifier (e.g., email address,instant message screen name, etc.). Once the user requests to invite oneor more friends (e.g., Friend 1 and Friend 2) to share in the fare forthe transport service, the fare split request 163 can be provided tosystem 100 with one or more communication identifiers for each of theselected friends (e.g., phone numbers, email addresses, etc.). Inaddition, the service application can provide an interface that liststhe friends selected by the user to share in the fare splitting andindicates the status of each of the selected friends (e.g., joined oraccepted, declined, not joined or pending, ditched). The status of theselected friends that have been invited can be dynamically adjusted.

The fee distribution 110 can receive the fare split request 163 via thedevice interface 150 and generate a request message 173 to be sent toselected friends of the user (e.g., Friend 1 and Friend 2). In oneexample, the fee distribution 110 can also include an amount determine112 and an account search 114. The amount determine 112 can determinethe amounts to be paid by each of the users friends that participate insplitting the fare for the transport service. The account search 114 canaccess the accounts data store 130 to determine whether one or morecommunication identifiers (for each of the selected friends determinedfrom the fare split request 163) match an account in the accounts datastore 130. In one example, the fee distribution 110 can tailor a requestmessage 173 to be sent to the one or more friends' devices 170 based onwhether or not the selected friend(s) have an existing account with theon-demand service system (e.g., if a friend does not have an existingaccount, the request message 173 that is sent to that friend can includea link that causes an application store program to be launched on thecomputing device on the download page of the service application).

In some examples, the request message 173 can include content thatindicates that the user wants to split the cost for the transportservice and a selectable link (e.g., a URL). The request message 173 canbe generated to also include the name of the user that requested thefare splitting. Depending on variation, the request message 173 can be atext message, such as a Short Message Service (SMS) message, amultimedia message, such as a Multimedia Messaging Service (MMS)message, or an email message. The request message 173 can be transmittedto the respective computing devices (referred to as friends' devices170) of the user's friends using the corresponding communicationidentifiers (e.g., a phone number or email address) via the deviceinterface 150.

The user's friends can receive the request message 173 and view thecontent of the request message 173 using a respective application (e.g.,an SMS application or an email application) that operates on thefriends' devices 170. The user's friend (e.g., Friend 1) can select thelink in the request message 173 to cause the service application (e.g.,if the service application is already installed on Friend 1's device170) to be launched on Friend 1's device 170. In this case, the serviceapplication can then display an in-application message with a promptrequesting Friend 1 to accept or decline the fare splitting request. Asan addition or an alternative, the link (e.g., a URL) in the requestmessage 173, when selected, can cause a browser application (or a tab ornew window for the browser application), for example, to be launched onFriend 1's device 170.

In some examples, a web page can be displayed in the browser applicationthat indicates that the user has requested to split the fare for thetransport service. The web page can include other information orfeatures, such as the name of the user, one or more images (e.g., animage of the user) and/or a selectable feature (or link). The selectablefeature, when selected, can cause the service application to beautomatically launched on the Friend 1's device 170 if the serviceapplication is already installed on Friend 1's device 170. On the otherhand, if the service application is not yet installed on Friend 1'sdevice 170 and/or if Friend 1 does not have an account set up with theon-demand service system, selection of the selectable feature can causethe application store program to be launched on Friend 1's device 170 sothat Friend 1 can have the option of downloading the serviceapplication. Friend 1 can choose to sign up with the on-demand servicesystem to create an account in order to participate in the faresplitting with the user (and/or others of the user's friends).

A user's friend that does not have an account with the on-demand servicesystem can choose to download the service application on his or hercomputing device 170 and create an account using one or morecommunication identifiers for the device 170, such as a phone number oran email address. The device 170 can transmit a new account request 177to system 100. The service manager 120 can update 123 the accounts datastore 130 with an entry for the new account corresponding to the user'sfriend. The user's friend can now operate the service application on hisor her device 170 to view an in-application message with a promptrequesting the friend to accept or decline the fare splitting request.

According to examples, the invited friends of the user can choosewhether to accept the invitation to share in the fare splitting with theuser or decline the invitation via the service application. For example,the user's friends can each choose to (i) select an “Accept” featureprovided on the prompt to share the fare, (ii) select a “Decline”feature provided on the prompt to not share the fare, or (iii) ignorethe request message 173 and/or the in-application message with theprompt by failing to select either the “Accept” or “Decline” features.When the user's friend makes a selection, the service application sendsan accept or decline communication 175 based on the selection to the feedistribution 110.

The fee distribution 110 receives the accept or decline communication175 from the user's friend, which includes an account identifier and/ora communication identifier for the user's friend or device 170. If oneof the user's friends (Friend 1) accepts the invitation, the feedistribution 110 associates Friend 1 with the transport service inprogress with the user. For example, the entry for the transport servicein progress can be updated in the service data store 140 (e.g., by thefee distribution 110 or by the service manager 120 that is incommunication with the fee distribution 110) to also be associated withthe identifier or account of Friend 1. On the other hand, if the user'sother friend (Friend 2) does not accept the invitation (e.g., ignoresit) or actively declines it, the fee distribution does not associateFriend 2's identifier or account with the transport service in progresswith the user. In this manner, the service manager 120 and/or the feedistribution 110 can keep track of which individuals and accounts areparticipating in sharing the fare with a particular transport service aswell as the user.

In one example, the user can continue to invite additional friends orremove friends from sharing in the fare until the payment has beenprocessed for the transport service. In other examples, the user cancontinue to invite additional friends or remove friends from sharing inthe fare until a time when system 100 determines that the transportservice is completed. For example, a driver can provide an indicationvia the service application on a provider device that transport servicehas been completed (e.g., destination has been reached). Similarly,friends that have been invited to share in the fare can choose to acceptthe invitation until the transport service is completed.

The service application operating on the user's requesting device 160(as well as the friends' devices 170) can provide an interface thatlists the friends selected by the user to share in the fare splitting.Each of the listed friends can have a status (e.g., joined or accepted,declined, not joined or pending, ditched) that can be dynamicallyupdated. The fee distribution 110, for example, can provide confirmationinformation 165 to the service application of the user's requestingdevice 160 when the fee distribution 110 receives accept or declinecommunications 175. In this manner, the user can see, in real-time orsubstantial real-time, which invited friends are sharing the cost forthe transport service as well as the status of those who have not yetresponded.

When the service manager 120 and/or the fee distribution 110 receives anindication that the transport service has been completed by the driver,the amount determine 112 can determine respective amounts 115 of thefare that the user and the user's friends sharing in the fare splittingare to pay. Depending on implementation, the amount determine 112 candesignate or assign a percentage of the fare (e.g., 25% or 50%) to eachof the user and the user's friends (to add up to 100%) or provide a flatrate amount that each of user and the user's friends is to pay based onthe total fare 125. For example, the service manager 120 can monitor thetransport service and determine a total fare 125 for the transportservice based on the duration and/or distance traveled by the driver inproviding the transport service. In another example, the amountdetermine 112 can determine the total fare 125 based on the serviceinformation 117 of the transport service from the service data store140.

Depending on variations, the amount determine 112 can determine therespective fare amounts 115 for the user and the user's friends who areparticipating in the fare splitting based on different factors. In oneexample, the user can provide input, when providing the fare splitrequest 163, to assign a percentage or amount for each friend invited toshare the fare, with the remainder of the fare to be assigned to theuser. In another example, the total fare 125 can be split evenly (orsubstantially evenly) between the total number of individuals that haveagreed to share in the fee. Still further, in other examples, the amountdetermine 112 can determine the respective fare amounts 115 based onother factors or parameters, such as the duration of the transportservice, the distance and/or direction(s) traveled by the driver inproviding the service, when the individuals agreed to share in the fare,when the individuals initially got in the vehicle providing thetransport service, when the individuals got out of the vehicle, etc. Theamount determine 112 can access or retrieve such information (e.g., theservice information 117) of the transport service from the service datastore 140.

For example, the user can request a transport service to get from point1 to point 2. At any time during progress of the transport service, theuser and one friend (e.g., Friend 1) can agree to share the fare for thetransport service. Friend 1 can choose to share the fare for the userwhether or not Friend 1 is actually riding with the user in the vehicle.In a case where the user and Friend 1 are picked up together by adriver, the service manager 120 can receive location information (aswell as the bearing/direction of travel) of the user, Friend 1, and/orthe driver via the respective computing devices. The locationinformation can be used to indicate to the service manager 120 that theuser and Friend 1 are together, and when the user and Friend 1 enter thedriver's vehicle together (e.g., the location information for all threeare substantially close together). If Friend 1 gets dropped off first,at point 3, and the driver continues to point 2 to drop off the user,the service manager 120 can use the location information of the user,Friend 1, and/or the driver to determine at what time and where Friend 1was dropped off and when and where the user was dropped off. Theinformation corresponding to this transport service can be provided inthe service data store 140.

Using this information, the amount determine 112 can determine how theamounts 115 for the fare can be distributed between the user andFriend 1. In one implementation, the amount determine 112 can split thefare evenly despite who got on first or got dropped off first. Inanother example, the amount determine 112 can base the fare amounts 115depending on the duration and/or distance traveled (e.g., one mile forFriend 1 from point 1 to point 3, then three miles for the user frompoint 3 to point 2, so the user pays for 75% while Friend 1 pays for25%). In some situations, this may not be a fair distribution as thedistance traveled can be dependent on the route chosen by the driver(e.g., the driver could have dropped off the user first and then droppedoff Friend 1 at point 3). The amount determine 112 can also determinethe amounts 115 based on the directions of travel to account for suchsituations. The amount determine 112 can calculate the amounts 115differently based on user configurations by an administrator of theon-demand service system or system 100.

Once the fee distribution 110 determines the fare amounts 115 for theuser and the user's friends, each fare amount 115 is associated with theindividuals participating in the fare splitting (e.g., associated withthe accounts for the user and the user's friends). The service manager120 can arrange for payment 127 to be made or charge the accounts (e.g.,charge a credit card or bank account of the user and the user's friendson file with the accounts) respectively based on the fare amounts 115.In this manner, the fare portions attributable to each individualparticipating in the fare splitting can be withdrawn from theirrespective associated accounts and transferred to an account of thedriver, an account of the transport service provider (e.g., company thatemploys the driver) or an account of the on-demand service provider.

As an addition or an alternative, the fee distribution 110 can enablethe user to share the fare for the transport service with one or moreother friends or contacts by providing the user with a code (e.g., anumeric or alphanumeric code). In one example, when the fare splitrequest 163 is made by the user operating the requesting device 160, thefee distribution 110 can provide the code (e.g., a four digit numericalcode, such as “1214”) to the service application of the user'srequesting device 160. The user can inform the his or her friends of thecode (e.g., verbally or send the code to the friends' devices) so thatthe friends who wish to participate in the fare splitting can access amenu/option settings on the service application on their respectivedevices 170 and input the code to share in the fare. For example, aselectable feature can be provided in the menu/option settings (e.g.,“split a trip fare”), so that when the selectable feature is selected, auser interface is provided that prompts the friend to enter or input acode from a transport service in progress. A friend's input of the codecan result in the accept communication 175 being provided to the feedistribution 110. The fee distribution 110 can then associate the friendwho inputted the code with the transport service in progress for theuser, such as described above.

Depending on implementation, the fee distribution 110 and/or the servicemanager 120 can generate a code for the user and/or the transportservice requested by the user at different times. For example, the codecan be generated when the transport service is initially requested bythe user. In another example, the code can be generated when the usermakes the fare split request 163. The code can then be associated withthe user and/or the transport service in the service data store 140and/or the accounts data store 130. In some examples, the code can betemporary (e.g., valid only for a duration of time, such as only duringthe progress of the transport service), so that when the transportservice is completed, the user cannot invite other friends to share inthe fare and/or the user's friends who have previously been invitedduring the progress of the transport service cannot participate in thefare splitting. In such cases, when the user requests another transportservice at a later time, another code can be generated and associatedwith that user and/or the transport service.

As another addition or alternative, the fee distribution 110 can enablethe user to share the fare for the transport service with one or moreother friends by generating a code (e.g., a numeric or alphanumericcode) and transmitting the code with the request message 173 to thefriends' devices 170. If the user invites a friend who has an existingaccount with the on-demand service system (e.g., determined by theaccount search 114, as discussed above), the friend can receive therequest message 173 with the code (e.g., “276” in the subject or body ofthe email or text message). The request message 173 can instruct thefriend to “reply to the message with the code ‘276’ to split the farewith User.” When the friend replies to the message with the appropriatecode, the fee distribution 110 can be notified that the friend hasaccepted to share the fare with the user. The friend's account can thenbe associated with the transport service in progress for the user. Inthis example, the friend can share in the fare without having to open orlaunch the service application on his or her device 170. Instead, thefriend can accept the invitation for fare splitting by operating therespective communication application (e.g., text message application oremail application).

As an addition or alternative, system 100 can also enable the user ofthe requesting device 160 to share information about the transportservice for the user with one or more friends or contacts. For example,a user who initiates/requests a transport service using the serviceapplication on his or her device 160 can also access a menu/optionssettings (e.g., while the transport service is in progress) to shareinformation about the transport service with friends or contacts. Whenthe user selects a “share ride information” feature from themenu/options settings, for example, a user interface is provided (by theservice application) that includes a link (e.g., URL) and a plurality ofselectable options indicating different mechanisms/methods for sharinginformation about the transport service. Each selectable option caninclude an icon corresponding to the respective mechanism/method forsharing the information. For example, the different mechanisms/methodscan include email, text or multimedia message, and/or social media post(e.g., FACEBOOK, TWITTER).

The link that is provided in the user interface of the serviceapplication can be generated and provided by the service manager 120. Asdiscussed, the service manager 120 can interface with or be a part ofthe on-demand service system and monitor the transport service inprogress for the user. The service manager 120 can generate a link thatis associated with and corresponds to the transport service for theuser. For example, the service manager 120 can generate the link whenthe on-demand service system arranges the transport service for the user(e.g., in response to the user's transport service request). The linkcan be a reference to a web page that provides a variety of informationabout the user's transport service.

For example, the information provided on the linked web page can includea pickup location, a pickup time, a destination location, estimated timeof arrival at the destination, the current position information of theuser and/or the driver, the status of the transport service (e.g.,driver is en route, driver is approaching, the user is in trip, etc.),information about the driver (e.g., the driver's name, vehicle type,license plate number, ratings information, a map showing the currentroute of travel and/or a projected route of travel, the speed of thevehicle traveling, etc.). The linked web page can dynamically update theinformation about the transport service in real-time or substantially inreal-time. For example, the web page can be provided with updatedinformation about the transport service as the transport service is inprogress (e.g., the on-demand service system and/or the service manager120 can update 121 information about the transport service in the datastore 140). The web page can also be adjusted (e.g., in size,resolution, layout) based on the type of computing device and/or browserprogram used to view the web page.

Using the service application, the user can select one of the pluralityof mechanisms/methods to share information about the transport servicewith friends or contacts. Selecting one of the mechanisms/methods cancause a window corresponding to that mechanism/method to be displayedwithin the service application. For example, the user can select the“text message” option. When the user makes a selection, e.g., selects ortoggles the selectable option, a window corresponding to the textmessage application can be displayed within the service application. Thewindow for the text message application can include or correspond to themessage that is being composed. In addition, the link that is associatedwith and corresponds to the transport service in progress for the usercan be included within the body of the message that is being composed.The user can also choose which friend(s) to send the message to. Whenthe user sends the message, the text message application can send themessage and the window corresponding to the text message application canbe removed or dismissed from the service application. In this manner,the user does not have to manually open or launch the text messageapplication, and the text message being composed can automaticallyinclude the link to send to the user's friends.

In some examples, the user can also be provided with a verification userinterface or privacy confirmation user interface. Such a user interfacecan provide the user with additional security before information aboutthe user's transport service is given to other people. For example, theuser can select the social media mechanism option as a means to shareinformation about the user's transport service. A post that includes thelink, such as on FACEBOOK or TWITTER, can enable a high number offriends or contacts to view the user's transport service information. Byprompting the user to confirm sharing the link before sending themessage or email, or publishing a status update or post on a socialmedia platform, the user is provided with an extra safekeepingmechanism.

Methodology

FIG. 2 illustrates an example method for splitting a fee for anon-demand service. A method such as described by an example of FIG. 2can be implemented using, for example, components described with anexample of FIG. 1. Accordingly, references made to elements of FIG. 1are for purposes of illustrating a suitable element or component forperforming a step or sub-step being described.

System 100 determines that the on-demand service is in progress for afirst user (210). The first user can operate a service application onthe user's computing device 160 that communicates with system 100. Inone example, the first user can request an on-demand service, such as atransport service, using the service application. When the on-demandservice system arranges for the transport service to be provided for thefirst user (e.g., by selecting a service provider for the first user),system 100 can determine that the transport service is in progress forthe first user. Depending on implementation, the transport service canbe determined to be in progress once the driver selected, when thedriver is en route to the location of the first user, when the driver isarriving to the first location, when the first user is being transportedto a destination, etc.

During progress of the transport service, system 100 can determine thatthe fare for the transport is to be shared by the first user and atleast one other user. In some examples, system 100 can make thisdetermination by receiving user inputs from computing devices 160, 170of the respective users. For example, the first user can operate theservice application on her device 160 to make a request to share thefare for the transport service with another user (e.g., Friend 1).System 100 can receive the request to share the fare for the transportservice (220). The request to share the fare can also include one ormore communication identifiers for Friend 1 (e.g., a cellular phonenumber, an email address).

System 100 can transmit a request message to the device 170 of Friend 1that notifies Friend 1 that the first user would like to share the costor fare for the transport service for the first user (230). Depending onimplementation, the request message can be transmitted using thecommunication identifier of Friend 1 and the corresponding communicationmedium (e.g., SMS, email). Friend 1 can choose to actively accept theinvitation to share the fare or actively decline the invitation, orsimply ignore the request message if he or she does not want toparticipate in fare splitting with the first user.

The request message can include a link that can be selected by Friend 1when viewed using a respective communication application on his or herdevice 170 (e.g., a text message application or email application).Depending on variation, the link can cause the service application to belaunched on the device 170 (if the service application is alreadyinstalled on Friend's device 170), cause the application store programto be launched on the device 170 (if the service application is not yetinstalled on Friend's device 170), or cause a browser application to belaunched on the device 170 that displays a web page indicating that thefirst user wants to share the fare for the transport service. The webpage displayed by the browser application can include a selectablefeature that, when selected by Friend, (i) launches the serviceapplication so that an in-application message is displayed in theservice application, prompting the user to accept or decline theinvitation to share the fare, or (ii) launches the application storeprogram if the service application is not yet installed on Friend'sdevice 170 and/or if Friend 1 does not have an account set up with theon-demand service system.

The invited friend, Friend 1, can choose to accept or decline theinvitation to share the fare with the first user. Once Friend 1 makes aselection of the prompt in the in-application message, an accept ordecline communication 175 based on the selection can be transmitted tosystem 100 (e.g., Friend 1 provides a response to the invitation).System 100 can receive the communication (240) and determine whether thecommunication is an acceptance or rejection of the invitation for faresplitting (250). If the communication is an acceptance to share thefare, system 100 can associate Friend 1 with the transport service inprogress for the first user (e.g., associate an account identifier ofFriend 1 with the transport service identifier and/or the accountidentifier of the first user) (255). System 100 can then determine theamount of the fare for the transport service that each participatingindividual (e.g., the first user and Friend 1) is to pay (260).

In some examples, the amount of the fare can be determined based oninput provided by the first user and/or the participating friends ordetermined to be split evenly (or substantially evenly) based on thenumber of participating parties. Still further, in other examples,system 100 can determine the respective fare amounts based on otherfactors or parameters, such as the duration of the transport service,the distance and/or direction(s) traveled by the driver in providing theservice, when the individuals agreed to share in the fare, when theindividuals initially got in the vehicle providing the transportservice, when the individuals got out of the vehicle, etc. Once thetransport service has been completed (and/or system 100 receives anindication, e.g., from the driver, that the transport service has beencompleted), system 100 can arrange for payment to be made or charge theaccounts (e.g., charge a credit card or bank account of the first userand of Friend 1) respectively based on the determined fare amounts(280).

On the other hand, if the communication is a rejection (e.g., Friend 1declines to share the fare), system 100 does not associate Friend 1 withthe transport service in progress for the first user. Instead, the fareamount for the transport service remains fully assigned to the firstuser (270). System 100 can arrange for payment to be made or charge theaccount of the first user (280). During the progress of the transportservice, however, the first user can continue to invite others to sharethe fare for the transport service (e.g., go back to step 220), andsystem 100 can transmit additional request messages to subsequentlyinvited individuals.

User Interface Examples

FIGS. 3A through 3E illustrate example user interfaces that aredisplayed on a computing device for splitting a fee for an on-demandservice. The user interfaces illustrate features that can be provided bya service application running on a computing device of a user orrequester of the service. Such an application can be provided by anentity that enables an on-demand service to be arranged between parties.The service application can enable data to be exchanged between thesystem 100 and the service application (as well as the computing devicein which the service application is operating on) so that a user of thecomputing device can view on-demand service information provided bysystem 100.

In one example, the user interface 300 a of FIG. 3A is provided by theservice application running on a user's computing device (e.g.,requesting device 160). In this example, the user has requested anon-demand service, such as a transport service, and the on-demandservice system has arranged for the transport service to be provided bya particular provider (e.g., a driver having the name, FirstNameLastName). The user interface 300 a can include an image 308 of theservice provider as well as information 310 about the service provider(such as the name, vehicle time, license plate number). The userinterface 300 a can also include a map 307 that shows the currentlocation of the user, the destination requested by the user, and/or thecurrent location of the driver.

During progress of the transport service, the user can access amenu/options settings by selecting (e.g., tapping on a touch-sensitivedisplay of the computing device or by providing other input(s) on aninput mechanism) the options feature 302 so that a menu window 304 isprovided to overlay the map 307. The menu window 304 can include aplurality of selectable options such as “contact driver,” “split fare,”“cancel trip,” or other features (not shown), such as “share rideinformation,” etc., to cause other user interfaces to be displayed basedon the selection. The user can select the “split fare” feature 306, forexample, to have the option of selecting friends or contacts to share inthe fare for the user's transport service.

When the user selects the “split fare” feature 306, a user interface 300b, such as illustrated in FIG. 3B, can be provided on the display of theuser's computing device. The user interface 300 b enables the user toselect which friends or contacts to invite to share in the fare for theuser's transport service. The service application can interface with orcommunicate with the user's contacts (e.g., the contacts application,phone book, or email addresses) to provide entries 312 corresponding tothe user's friends or contacts. In one example, the list of entries 312can be partitioned to show one or more entries 312 that the user hasrecently and/or frequently used to share in the fare. For example,section 314 can show the most recently selected friends the user hasselected to share in the fare (e.g., selected in the past three days orpast week).

The user can select one or more entries 312 corresponding to friends forsharing the fare for the transport service. When the user makes aselection, an indication 318 can be provided and/or the names 320 can beshown in the selection field 316. In some examples, the selection field316 can also provide the user with another option of selecting users.The user can select a region within the selection field 316 to cause akeyboard or number pad, for example, to be displayed on the userinterface 300 b. In this manner, the user can input the friend's nameand/or input a communication identifier of the friend the user wants toinvite (e.g., a cell phone number or email address). In the exampleillustrated in FIG. 3B, the user has currently selected “John Doe 1” and“John Doe 3” to invite to share the fare for the user's transportservice.

Once the user makes the selections, the user can select the “send”feature 322. When the user selects the “send” feature 322, the serviceapplication can send a fare split request to the on-demand servicesystem and/or system 100, as described in FIG. 1, with identifyinginformation of the selected friends (e.g., names and/or phone numbersand/or email addresses).

In addition, when the user selects the “send” feature 322, the serviceapplication can provide a user interface 300 c to be displayed on theuser's computing device, as illustrated in FIG. 3C. The user interface300 c can correspond to a confirmation page that indicates to the userwhich friends the user has invited to split the fare for the transportservice. The user interface 300 c can include entries 330 that indicatewhich friends or contacts the user has invited and the names andcommunication identifiers (e.g., phone number and/or email address) forthose friends. The user interface 300 c can also include a selectablefeature 332 to enable the user to invite other/additional friends orcontacts and instructional text 336 to better inform the user.

In one example, each of the entries 330 can include a status identifier334 in the form of text and/or graphics that indicate the current statusof the invited friends. For example, the circular graphic can looparound indicating that the invitation is pending because the friend hasnot yet responded to the request to share the fare. The statusidentifiers 334 can be dynamically updated (e.g., via confirmationinformation 165 provided by system 100 in FIG. 1) by the serviceapplication on the user's device. Other status identifiers 334 caninclude a check symbol or the text “accepted” when a friend joins, thetext “declined” when the friend actively declines the invitation, or thetext “left trip” when the friend accepts and then declines at a latertime. Each of the entries 330 can also include a cancel feature, asindicated by the “X” symbol, to enable the user to cancel the faresplitting invitation to the particular friend. An entry 330 can alsoindicate that the corresponding friend does not have an account with theon-demand service system (e.g., based on the search performed by thesystem).

FIG. 3D illustrates a user interface 300 d when the user selects the“done” feature on the user interface 300 c. The user interface 300 dshows the current progress of the transport service for the user. Forexample, the user interface 300 d can include similar features describedwith respect to the user interface 300 a of FIG. 3A. The map can depicta current location 340 of the user as well as the estimated time ofarrival 342 of the driver to the user. In other examples, the locationmarker 340 can correspond to the current location of the driver or thedestination location for the transport service, while the estimated timeof arrival 342 can correspond to the estimated time in which thetransport service will be completed.

In addition to such features, the user interface 300 d can also includea notification 344 that provides an indication that the user issplitting the fare with two other people so far (e.g., two friends haveaccepted the request). The user can select an expansion feature 346 toview detailed information about who the user is splitting the fare with.For example, when the user selects the expansion feature 346, a pop-upfeature 350 can be provided by the service application (as illustratedby the user interface 300 e in FIG. 3E). The pop-up feature 350 can showthe user's name (“User Name 1”) as well as the invited users and theirrespective statuses. In this example, two users have accepted to sharein the fare (“John Doe 1” and “John Doe 7”) while one user has not yetresponded, as indicated by the “pending” graphic (“John Doe 3”).

FIGS. 4A through 4C illustrate other example user interfaces that aredisplayed on a computing device for splitting a fee for an on-demandservice. As discussed, a friend (e.g., “John Doe 1”) operating thedevice can receive a request message, e.g., in the form of a textmessage or email message, from the on-demand service system. In oneexample, when the friend selects the link provided in the requestmessage, the user interface 400 a of FIG. 4A can be provided by abrowser application on the friend's computing device. The link can be aURL, for example, that directs the browser application to open a webpage that provides additional information about the fare splittingrequest to the friend. In one example, the web page can provide graphics410 as well as content 420 that indicate that the user wants to splitthe fare for the transport service. The web page can also include aselectable feature 430 that can either (1) cause the service applicationrunning on the computing device of the friend to be launched (if thefriend has the service application installed on his or her device) or(2) cause the application store program to be launched (if the frienddoes not have the service application installed on his or her device).

In FIG. 4B, the user interface 400 b can be provided by the serviceapplication once the service application is launched on the friend'scomputing device. The user interfaces 400 b and 400 c illustratefeatures that are provided by the service application running on thecomputing device of the friend that has received a request to share inthe fare for a user's on-demand service. When the service application islaunched, in-application message or prompt 440 is automaticallydisplayed on the friend's computing device. The prompt 440 can show agraphic and/or name of the user requesting to share the fare, along withan accept feature 450 and a decline feature 460. The selection of thefeatures 450, 460 can cause the service application to transmit anaccept or decline communication to the service system.

When the friend declines the invitation, the service application candisplay the typical home page. On the other hand, when the friendaccepts the invitation, the service application can display a userinterface 400 c, as illustrated in FIG. 4C, to show information aboutthe current transport service in progress for the user in which thefriend has accepted to share the fare. In some example, the userinterface 400 c can include similar features as described with the userinterface 300 a and 300 d of FIGS. 3A and 3D. The user interface 400 ccan also include a notification 470 that provides an indication that thefriend is splitting the fare with two other people so far (e.g., theuser and the other friend who have accepted the request). The friend canselect an expansion feature to view detailed information about who thefriend is splitting the fare with. In one example, the informationdisplayed to the friend can be less detailed than the informationdisplayed to the user (e.g., show only names of the individualsparticipating in the fare splitting and do not show phone numbers oremail addresses).

Hardware Diagrams

FIG. 5 is a block diagram that illustrates a computer system upon whichexamples described herein may be implemented. For example, in thecontext of FIG. 1, system 100 may be implemented using a computer systemsuch as described by FIG. 5. System 100 may also be implemented using acombination of multiple computer systems as described by FIG. 5.

In one implementation, computer system 500 includes processing resources510, main memory 520, ROM 530, storage device 540, and communicationinterface 550. Computer system 500 includes at least one processor 510for processing information. Computer system 500 also includes a mainmemory 520, such as a random access memory (RAM) or other dynamicstorage device, for storing information and instructions to be executedby the processor 510. Main memory 520 also may be used for storingtemporary variables or other intermediate information during executionof instructions to be executed by processor 510. Computer system 500 mayalso include a read only memory (ROM) 530 or other static storage devicefor storing static information and instructions for processor 510. Astorage device 540, such as a magnetic disk or optical disk, is providedfor storing information and instructions.

The communication interface 550 can enable the computer system 500 tocommunicate with one or more networks 580 (e.g., cellular network)through use of the network link (wireless or wireline). Using thenetwork link, the computer system 500 can communicate with one or morecomputing devices and/or one or more servers. In some variations, thecomputer system 500 can be configured to receive a fare split request582 from one or more computing devices (e.g., a user's computing device)via the network link. The fare split request 582 can be processed by theprocessor 510 and information included in the request 582 can be storedin, for example, the storage device 540. For example, the processor 510can process the request 582 to determine which computing devices totransmit a request message to in order to invite the appropriate friendsto share the fare for the user's transport service. The request messagecan be generated and then transmitted to the appropriate computingdevice(s) of the user's friend(s) over the network 580. The computersystem 500 can also receive an accept or decline communication 584 fromthe computing devices based on whether the friend(s) choose to accept ordecline the invitation for fare splitting.

Computer system 500 can also include a display device 560, such as acathode ray tube (CRT), an LCD monitor, or a television set, forexample, for displaying graphics and information to a user. An inputmechanism 570, such as a keyboard that includes alphanumeric keys andother keys, can be coupled to computer system 500 for communicatinginformation and command selections to processor 510. Other non-limiting,illustrative examples of input mechanisms 570 include a mouse, atrackball, touch-sensitive screen, or cursor direction keys forcommunicating direction information and command selections to processor510 and for controlling cursor movement on display 560.

Examples described herein are related to the use of computer system 500for implementing the techniques described herein. According to oneexample, those techniques are performed by computer system 500 inresponse to processor 510 executing one or more sequences of one or moreinstructions contained in main memory 520. Such instructions may be readinto main memory 520 from another machine-readable medium, such asstorage device 540. Execution of the sequences of instructions containedin main memory 520 causes processor 510 to perform the process stepsdescribed herein. In alternative implementations, hard-wired circuitrymay be used in place of or in combination with software instructions toimplement examples described herein. Thus, the examples described arenot limited to any specific combination of hardware circuitry andsoftware.

FIG. 6 is a block diagram that illustrates a mobile computing deviceupon which examples described herein may be implemented. In one example,a computing device 600 may correspond to a mobile computing device, suchas a cellular device that is capable of telephony, messaging, and dataservices. Examples of such devices include smartphones, handsets ortablet devices for cellular carriers. Computing device 600 includes aprocessor 610, memory resources 620, a display device 630 (e.g., such asa touch-sensitive display device), one or more communication sub-systems640 (including wireless communication sub-systems), input mechanisms 650(e.g., an input mechanism can include or be part of the touch-sensitivedisplay device), and one or more location detection mechanisms (e.g.,GPS component) 660. In one example, at least one of the communicationsub-systems 640 sends and receives cellular data over data channels andvoice channels.

The processor 610 is configured with software and/or other logic toperform one or more processes, steps and other functions described withimplementations, such as described by FIGS. 1 through 4, and elsewherein the application. Processor 610 is configured, with instructions anddata stored in the memory resources 620, to operate a serviceapplication, for example, as described in FIGS. 1 through 4C. Forexample, instructions for operating the service application in order todisplay various user interfaces, such as described in FIGS. 3A through4C, can be stored in the memory resources 620 of the computing device600. A user can operate the service application to make a request 641 toshare the fare for a transport service with one or more friends orcontacts. In addition, the service application running on the user'scomputing device 600 can receive confirmation information 643 thatprovides to the user the current status of the friends who received theinvitations.

Similarly, a friend can operate a similar computing device 600 that alsoruns a service application. The friend can receive a request message 645from an on-demand service system that invites the friend to share thefare for the transport service with the user. The service applicationcan provide an accept or decline communication 647 based on the friend'sselection to accept or decline the invitation. For both the user and thefriend, the communication sub-systems 640 of the devices can enableinformation to be exchanged between the devices and the on-demandservice system.

The processor 610 can provide content to the display 630 by executinginstructions and/or applications that are stored in the memory resources620. In some examples, user interfaces 615 can be provided by theprocessor 610, such as a user interface for the service application(e.g., including a heat map user interface). While FIG. 6 is illustratedfor a mobile computing device, one or more examples may be implementedon other types of devices, including full-functional computers, such aslaptops and desktops (e.g., PC).

It is contemplated for examples described herein to extend to individualelements and concepts described herein, independently of other concepts,ideas or system, as well as for examples to include combinations ofelements recited anywhere in this application. Although examples aredescribed in detail herein with reference to the accompanying drawings,it is to be understood that the examples are not limited to thoseprecise descriptions and illustrations. As such, many modifications andvariations will be apparent to practitioners. Accordingly, it iscontemplated that a particular feature described either individually oras part of an example can be combined with other individually describedfeatures, or parts of other examples, even if the other features andexamples make no mention of the particular feature.

What is being claimed is:
 1. A non-transitory computer-readable mediumstoring instructions that, when executed by one or more processors of anetwork computing system, causes the network computing system to:associate each of an identifier of a first user and an identifier of aprovider with a data record of a service, the data record being storedin a data store accessible by the network computing system; monitor aprogress of the service by at least periodically receiving location datafrom a computing device operated by the provider over one or morenetworks, wherein the location data corresponds to a current location ofthe provider; at a time prior to completion of the service, receive,over the one or more networks from a computing device of the first user,data corresponding to a request to provide information about the serviceto a second user that is not the provider, the data corresponding to therequest including a communication identifier associated with the seconduser; and dynamically provide, over the one or more networks, updatedinformation about the service to a computing device associated with thesecond user based on the communication identifier, the updatedinformation about the service being based, at least in part, on locationdata from the computing device operated by the provider.
 2. Thenon-transitory computer-readable medium of claim 1, wherein theinstructions cause the network computing system to monitor the progressof the service by determining at least a time of arrival to a startlocation of the service or a time of arrival to an end location of theservice.
 3. The non-transitory computer-readable medium of claim 2,wherein the updated information about the service includes informationabout the time of arrival to the start location or the time of arrivalto the end location.
 4. The non-transitory computer-readable medium ofclaim 2, wherein the updated information about the service includes datacorresponding to a route of travel or a proposed route of travel to bedisplayed on a map user interface of the computing device associatedwith the second user.
 5. The non-transitory computer-readable medium ofclaim 1, wherein execution of the instructions further causes thenetwork computing system to: provide information about the provider,including a name, vehicle type, and license plate number.
 6. Thenon-transitory computer-readable medium of claim 1, wherein execution ofthe instructions further causes the network computing system to: updatethe data record of the service with location data from the computingdevice operated by the provider.
 7. The non-transitory computer-readablemedium of claim 1, wherein execution of the instructions further causesthe network computing system to: provide, over the one or more networks,updated information about the service to the computing device of thefirst user.
 8. The non-transitory computer-readable medium of claim 1,wherein execution of the instructions further causes the networkcomputing system to: transmit, over the one or more networks, a messageto the computing device associated with the second user using thecommunication identifier prior to dynamically providing updatedinformation about the service to the computing device associated withthe second user.
 9. The non-transitory computer-readable medium of claim1, wherein the instructions cause the network computing system tomonitor the progress of the service by determining a status of theprovider.
 10. The non-transitory computer-readable medium of claim 9,wherein the updated information about the service includes informationabout the status of the provider.
 11. A network computing systemcomprising: one or more processors; and a memory that stores a set ofinstructions, wherein the set of instructions, when executed by the oneor more processors, causes the network computing system to: associateeach of an identifier of a first user and an identifier of a providerwith a data record of a service, the data record being stored in a datastore accessible by the network computing system; monitor a progress ofthe service by at least periodically receiving location data from acomputing device operated by the provider over one or more networks,wherein the location data corresponds to a current location of theprovider; at a time prior to completion of the service, receive, overthe one or more networks from a computing device of the first user, datacorresponding to a request to provide information about the service to asecond user that is not the provider, the data corresponding to therequest including a communication identifier associated with the seconduser; and dynamically provide, over the one or more networks, updatedinformation about the service to a computing device associated with thesecond user based on the communication identifier, the updatedinformation about the service being based, at least in part, on locationdata from the computing device operated by the provider.
 12. The networkcomputing system of claim 11, wherein the set of instructions cause thenetwork computing system to monitor the progress of the service bydetermining at least a time of arrival to a start location of theservice or a time of arrival to an end location of the service.
 13. Thenetwork computing system of claim 12, wherein the updated informationabout the service includes information about the time of arrival to thestart location or the time of arrival to the end location.
 14. Thenetwork computing system of claim 12, wherein updated the informationabout the service includes data corresponding to a route of travel or aproposed route of travel to be displayed on a map user interface of thecomputing device associated with the second user.
 15. The networkcomputing system of claim 11, wherein execution of the set ofinstructions further cause the network computing system to: transmitinformation about the provider, including a name, vehicle type, andlicense plate number.
 16. The network computing system of claim 11,wherein execution of the set of instructions further cause the networkcomputing system to: update the data record of the service with locationdata from the computing device operated by the provider.
 17. The networkcomputing system of claim 11, wherein execution of the set ofinstructions further cause the network computing system to: provide,over the one or more networks, updated information about the service tothe computing device of the first user.
 18. The network computing systemof claim 11, wherein execution of the set of instructions further causethe network computing system to: transmit, over the one or morenetworks, a message to the computing device associated with the seconduser using the communication identifier prior to dynamically providingupdated information about the service to the computing device associatedwith the second user.
 19. The network computing system of claim 11,wherein the set of instructions cause the network computing system tomonitor the progress of the service by determining a status of theprovider, and wherein the information about the service includesinformation about the status of the provider.
 20. A method of providingmonitored data to a device, the method being performed by a networkcomputing system and comprising: associating each of an identifier of afirst user and an identifier of a provider with a data record of aservice, the data record being stored in a data store accessible by thenetwork computing system; monitoring a progress of the service by atleast periodically receiving location data from a computing deviceoperated by the provider over one or more networks, wherein the locationdata corresponds to a current location of the provider; at a time priorto completion of the service, receiving, over the one or more networksfrom a computing device of the first user, data corresponding to arequest to transmit information about the service to a second user thatis not the provider, the data corresponding to the request including acommunication identifier associated with the second user; anddynamically providing, over the one or more networks, updatedinformation about the service to a computing device associated with thesecond user based on the communication identifier, the updatedinformation about the service being based, at least in part, on locationdata from the computing device operated by the provider.